Method, apparatus, system, and article of manufacture for providing distributed convergence nodes in a communication network environment

ABSTRACT

A system, apparatus, article of manufacture, and method provides one or more distributed convergence nodes referred to as “Supernodes”, each of which is embodied as a functional technology component within an application that automatically determines whether said component should become “active” and assume the responsibility of forwarding IP multicast data present on a LAN (which supports IP multicast communication) to a “Routing Supernode” via a WAN (which does not support IP multicast communication). The Routing Supernode, in turn, is responsible for forwarding that traffic to other Supernodes present on other LANs. The traffic sent to and from the Routing Supernode is sent via unicast communication. All Supernodes are responsible not only for forwarding traffic present on their respective LAN across the WAN to a Routing Supernode, but they are also responsible for forwarding traffic received over the WAN from the Routing Supernode onto their own respective LANs. An election process determines which device in a LAN is to operate as a SuperNode.

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to and the benefit under 35U.S.C. §119(e) of U.S. Provisional Patent Application Ser. No.60/908,878, entitled “METHOD, APPARATUS, SYSTEM, AND ARTICLE OFMANUFACTURE FOR PROVIDING SUPERNODES IN A COMMUNICATION NETWORKENVIRONMENT,” filed Mar. 29, 2007, assigned to the same assignee as thepresent application, and incorporated herein by reference in itsentirety.

TECHNICAL FIELD

This disclosure relates generally to computer software and/or hardwarefor computer and communication systems networking, and more particularlybut not exclusively relates to communication between devices through acommunication network.

BACKGROUND INFORMATION

Highly scalable, high-bandwidth applications such as voice over IP(VOIP) systems frequently utilize Internet Protocol (IP) multicasttechnologies to efficiently distribute audio communications amongstlarge numbers of users. While an extremely efficient use of availablenetwork bandwidth, configuration of the IP multicast infrastructure canbe an administratively intensive task requiring the cooperation andcoordination of numerous stakeholders and their organizations. As thedistribution of IP multicast data becomes even more widespread within anorganization and between organizations, the administrative taskincreases exponentially, resulting in increased costs and time beingincurred to set up and maintain the network infrastructure.

The issue of network infrastructure maintenance becomes even morecomplex and time-consuming when the distribution of IP multicast data isrequired over Wide Area Networks (WANs)—as opposed to the (relatively)simple task of distributing such IP multicast traffic over Local AreaNetworks (LANs).

BRIEF SUMMARY

One aspect provides a method for communicating in a communicationnetwork environment, the environment including at least a first, asecond, and a third local area network (LAN) separated from each otherby a wide area network (WAN), the LANs being IP-multicast-capable andthe WAN being non-IP-multicast-capable. The method includes:

electing a device in the first LAN as a first distributed convergencenode;

designating a device in the second LAN as a second distributedconvergence node, the second distributed convergence node being arouting distributed convergence node;

electing a device in the third LAN as a third distributed convergencenode; and

communicating traffic between the first and third distributedconvergence nodes via the routing distributed convergence node, whereinthe traffic can be communicated between devices within each of the LANsusing IP multicast communication, and wherein the traffic can becommunicated between the first distributed convergence node and therouting distributed convergence node and between the routing distributedconvergence node and the second distributed convergence node usingunicast communication.

Another aspect provides a system for communicating in a communicationnetwork environment, the environment including at least a first, asecond, and a third local area network (LAN) separated from each otherby a wide area network (WAN), the LANs being IP-multicast-capable andthe WAN being non-IP-multicast-capable. The system includes:

first distributed convergence node means in the first LAN forcommunicating traffic with devices in the first LAN using IP multicastcommunication and for communicating traffic from the devices over theWAN via unicast communication;

second distributed convergence node means in the second LAN forreceiving the traffic communicated via unicast communication over theWAN from the first distributed convergence node means, the seconddistributed convergence node means being a routing distributedconvergence node means for forwarding the traffic over the WAN usingunicast communication;

third distributed convergence node means in the third LAN for receivingthe traffic communicated by the routing distributed convergence nodeover the WAN using unicast communication, the third distributedconvergence node means further being for distributing the receivedtraffic to devices in the third LAN via IP multicast communication andfor communicating traffic from the devices over the WAN to the routingdistributed convergence node via unicast communication; and

electing means for electing a device as first, second, and thirddistributed convergence nodes, the distributed convergence nodes beingdynamically changeable as a result of the electing.

Still another aspect provides an apparatus adapted to be used in acommunication network environment, the environment including at least afirst, a second, and a third local area network (LAN) separated fromeach other by a wide area network (WAN), the LANs beingIP-multicast-capable and the WAN being non-IP-multicast-capable. Theapparatus includes:

a device having a distributed convergence node module, the distributedconvergence node module including:

an elector module to elect the device as a first distributed convergencenode in the first LAN;

an identifier module to identify the device from other devices in thefirst LAN, including identification of the device as the elected firstdistributed convergence node; and

a network interface in cooperation with a processor to communicate withthe other devices in the first LAN using IP multicast communication andto communicate with a routing distributed convergence node in the secondLAN via the WAN using unicast communication if the device is elected asthe first distributed convergence node, so as to allow the routingdistributed convergence node to forward communication via the WANbetween the first distributed convergence node in the first LAN and athird distributed convergence node in the third LAN.

Yet another aspect provides an apparatus adapted to be used in acommunication network environment, the environment including at least afirst, a second, and a third local area network (LAN) separated fromeach other by a wide area network (WAN), the LANs beingIP-multicast-capable and the WAN being non-IP-multicast-capable. Theapparatus includes:

a device having a routing distributed convergence node module, therouting distributed convergence node module including:

an elector module to elect the device as a routing distributedconvergence node in the second LAN;

an identifier module to identify the device from other devices in thesecond LAN, including identification of the device as the electedrouting distributed convergence node; and

a network interface in cooperation with a processor to communicate withthe other devices in the second LAN using IP multicast communication andto communicate with a first distributed convergence node in the firstLAN via the WAN using unicast communication and to communicate with athird distributed convergence node in the third LAN via the WAN usingunicast communication, so as to forward traffic between the first andthird distributed convergence nodes over the WAN.

Still another aspect provides an article of manufacture adapted to beused in a communication network environment, the environment includingat least a first, a second, and a third local area network (LAN)separated from each other by a wide area network (WAN), the LANs beingIP-multicast-capable and the WAN being non-IP-multicast-capable. Thearticle of manufacture includes:

a computer-readable medium adapted to be installed in one of the devicesand having computer-readable instructions stored thereon that areexecutable by a processor to:

elect the device as a distributed convergence node;

identify the device from other devices in a same LAN as the device,including identification of the device as the elected distributedconvergence node; and

communicate with the other devices in the same LAN using IP multicastcommunication and communicate with another distributed convergence nodevia the WAN using unicast communication, so as to enable transparentcommunication between distributed convergence nodes of different LANsvia the WAN using unicast communication in a manner that makes the WANappear to be IP-multicast-capable.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments are described with referenceto the following figures, wherein like reference numerals refer to likeparts throughout the various views unless otherwise specified or unlessthe context is otherwise.

FIG. 1 is a logical system block diagram according to one embodiment.The diagram shows the manner in which a variety of endpoints (200-Athrough 200-C, 200-D through 200-F, 200-G through 200-I, and 200-Jthrough 200-L) are each capable of communicating over IP multicastwithin their own IP multicast islands (110-A, 110-B, 110-C, and 110-Drespectively), but are not able to communicate via IP multicast over theunicast network 120. In this embodiment, endpoints 200-F, 200-G, and200-K establish unicast connections (300-A, 300-B, and 300-Crespectively) across the unicast network 120 to a routing node 200-A.

FIG. 2 is a logical system block diagram in accordance with oneembodiment. The diagram shows the manner in which, within an endpointdevice 200, an application module 210 logically couples to an instance400 of an embodiment. The instance 400, in turn, is coupled to the localnetwork using IP multicast 100 as well as the unicast network 120.

FIG. 3 is a logical system block diagram depicting example componentsaccording to one embodiment 400.

FIG. 4 a logical state transition diagram according to one embodiment.The diagram depicts the state transition model followed by an electormodule 420 in determining whether a node is to transition between activeand inactive states.

FIG. 5 a logical flow chart diagram according to one embodiment. Thediagram depicts the procedure followed within an identifier module 430to determine site identification amongst nodes on an IP multicastnetwork.

FIG. 6 is a logical flow chart diagram according to one embodiment. Thediagram describes the procedure followed within a processor module 440to forward data traffic received into the module 400 either through thecapture of data traffic to or from the local IP multicast 100 or of datatraffic received over the unicast WAN connection 120.

FIG. 7 is logical transaction diagram according to one embodiment. Thediagram shows the interaction between a Supernode 400-A, a RoutingSupernode 400-B, and a third Supernode 400-C. The various stages ofinteraction include a session setup stage 900-A, a registration stage900-B, a data streaming stage 900-C, an unregistration stage 900-D, anda session teardown stage 900-E. To reduce complexity of the diagram,only stage 900-C is depicted as including Supernode 400-C. It should beunderstood that the same interaction present between nodes 400-A and400-B is present between nodes 400-C and 400-B, as well as between otherSupernodes that may be present.

DETAILED DESCRIPTION

In the following description, numerous specific details are given toprovide a thorough understanding of embodiments. The embodiments can bepracticed without one or more of the specific details, or with othermethods, components, materials, etc. In other instances, well-knownstructures, materials, or operations are not shown or described indetail to avoid obscuring aspects of the embodiments.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment. Thus, the appearances of the phrases “in oneembodiment” or “in an embodiment” in various places throughout thisspecification are not necessarily all referring to the same embodiment.Furthermore, the particular features, structures, or characteristics maybe combined in any suitable manner in one or more embodiments.

Unless the context requires otherwise, throughout the specification andclaims which follow, the word “comprise” and variations thereof, suchas, “comprises” and “comprising” are to be construed in an open,inclusive sense, that is as “including, but not limited to.”The headingsprovided herein are for convenience only and do not interpret the scopeor meaning of the embodiments.

One solution to problems described above is an embodiment wherein thevery applications themselves that are used by users on their computers(or other types of devices) for communications with other such deviceseffectively become part of the network routing infrastructure,coordinating with other instances of the applications to efficientlydistribute IP multicast data—especially but not exclusively over the WANor other network where the most administrative complexity is required onan on-going basis. Such technology (including related functionality) isreferred to at times herein as “Supernode(s)” and/or as equivalently asone or more “distributed convergence nodes” and/or more generally as atleast one convergence node (including a plurality of convergence nodesor individual distributed convergence nodes).

At least some portions of the various embodiments of the Supernodetechnology can be implemented in conjunction with the various systems,apparatus, articles of manufacture, and/or methods disclosed in U.S.patent application Ser. No. 10/977,115, entitled “WIDE AREA VOICEENVIRONMENT MULTI-CHANNEL COMMUNICATIONS SYSTEM AND METHOD,” filed Oct.29, 2004, assigned to the same assignee (Twisted Pair Solutions, Inc.)as the present application, and incorporated herein by reference in itsentirety.

According to one embodiment, a Supernode includes a functionaltechnology component within an application that automatically determineswhether it (the component) should become “active” and assume theresponsibility of forwarding IP multicast data present on the LAN (orother network) across the WAN (or other network) to a “RoutingSupernode” which, in turn, is responsible for forwarding that traffic toother Supernodes present on other LANs (or other networks). AllSupernodes are responsible not only for forwarding traffic present onthe LAN (or other network) across the WAN (or other network) to aRouting Supernode, but they are also responsible for forwarding trafficreceived over the WAN (or other network) from the Routing Supernode ontotheir own LANs (or other network)—thereby creating the appearance of a“flat” IP multicast network to the hosting application along with othermulticast applications on the LAN (or other network). In effect, adevice at location A (e.g., New York) can transparently communicate withanother device at location B (e.g., Los Angeles) across what eachbelieve to be a fully IP multicast enabled network. A feature though isthat Supernodes at each location along with one or more RoutingSupernodes are in actuality creating the appearance of a virtual “flat”IP multicast network even though IP multicast is truly only present ateach location (the individual LANs or other networks) but not betweenthe locations (across the WAN or other network). Such locations where IPmulticast is available to applications but is bordered at some physicalor logical boundary—beyond which IP multicast does not flow—is referredto herein as a “multicast island”.

A feature with Supernodes according to an embodiment is that they arepart of the applications themselves (and not separate solutions), andthat the Supernode components present within each applicationcommunicate with each other in near real-time over the IP network todetermine which component housed on which device on the network willbecome the forwarding entity.

One embodiment's use in the form of an end-user application in a clientdevice is not its only implementation. Another embodiment is also usedon non-user computing devices such as server computers and specializedappliances. In either case (end-user or otherwise), the samefunctionality afforded by the embodiment(s) to one implementation may beafforded the other.

The functionality of the embodiment(s) is to create a virtualized IPmulticast network comprising of two or more IP multicast enablednetworks separated by one or more non-IP multicast capable networks. Assuch, an embodiment is responsible for inserting itself into anapplication or device designed for IP multicast such that data receivedfrom and transmitted to the IP multicast network by the application ordevice is relayed by unicast connection across the intervening non-IPmulticast enabled networks. The result of this operation is thatapplications or devices across the entire network—including those ondifferent sides of non-IP multicast enabled networks—are capable ofcommunicating with each other using IP multicast even though IPmulticast is not available end-to-end across the entire network.

For the sake of simplicity of explanation hereinafter, the variousnetworks in which the embodiments are implemented will be described interms of LANs and WANs. Embodiments may be implemented in other types ofnetworks, which may be variations and/or combinations of WANs and LANs,or completely different from WANs and LANs.

As depicted in FIG. 1, in an embodiment, routing node 200-A functions toroute traffic received across unicast connections 300-A, 300-B, and300-C to all other unicast connections (and thus operates as a routingSupernode or as a routing distributed convergence node), as well asfunctioning to forward such traffic to its own local IP multicastnetwork 100-A. Nodes receiving traffic over unicast connection fromrouting node 200-A follow similar operation—forwarding such traffic totheir own respective IP multicast networks. For example: data receivedby routing node 200-A from endpoint 200-F over unicast connection 300-Ais routed by routing node 200-A to endpoints 200-G and 200-K over theirrespective unicast connections 300-B and 300-C. In addition, routingnode 200-A functions to forward traffic received over unicastconnections to the local IP multicast network 100-A thereby making suchtraffic available to endpoints 200-B and 200-C. Similarly, endpointsreceiving unicast traffic across the Wide Area Network 120 function toforward such traffic to their own local IP multicast network, makingsuch traffic available to endpoints local to their respective networks.For example: traffic received from routing node 200-A by endpoint 200-Kover unicast connection 300-C is forwarded by endpoint 200-K to thelocal IP multicast network 100-D making such traffic available asmulticast traffic to endpoints 200-J and 200-L. In addition, nodes200-A, 200-F, 200-G, and 200-K also serve to forward traffic receivedover the unicast WAN 120 to the application they are hosted within orcoupled to, so as to create the same appearance of virtualized IPmulticast for the hosting/coupled application as is created for othernodes on each node's respective local IP multicast network.

In one embodiment, each of said endpoints is associated with a networkaddress, such as an IP address. The network address of any particularendpoint designated/elected as a Supernode or as a Routing Supernode canbe made known to all other Supernodes. The address can be made known,for example, by statically programming or otherwise providing eachSupernode with the IP address of a Routing Supernode. Alternatively oradditionally, the IP address of the Routing Supernode can be made knownto other Supernodes in a dynamic manner, such as by broadcasting theaddress or otherwise communicating the address to the variousSupernodes.

According to various embodiments, the nodes 200 may implemented on or asa device such as a client device and/or on non-user computing devicessuch as server computers and specialized appliances. Examples of clientdevices include, but are not limited to, personal computers (PCs),laptops, wireless devices (such as cellular telephones, PDAs, and soforth), set top boxes, and/or any other portable or stationaryelectronic communication device that can have network connectivity.Examples of non-user devices can include servers (as mentioned above),routers, switches, and other wireless and/or hardwired device that canhave network connectivity.

Node Election

An embodiment of a Supernode module 400 as depicted in FIG. 2 and FIG.3, upon learning of the unique IP address/port pairs of the IP multicastdata streams that an application 210 is currently processing, creates astate machine within itself in elector module 420 to represent thatparticular address/port pair. Such learning may occur in a multitude ofways including, but not limited to, static configuration, via anapplication programming interface 410 provided to the application by anembodiment, and through insertion in the pathway between the applicationand the IP multicast network.

In a similar embodiment, the elector module 420 is responsible fordetermining whether the current instance of the embodiment will beresponsible for processing IP multicast traffic across a unicastnetwork, or whether another instance on the same IP multicast networkwill be the responsible proxy entity. Such determination of a state ofbeing active or inactive is made through a state machine diagrammed inFIG. 4 wherein an election token, once generated by each instance of theelector on the network, is utilized in conjunction with the statemachine's operation. The token may take the form of a simple randomnumber or be calculated using varying degrees of sophisticationincluding, but not limited to, the device's current resource utilizationincluding, but not limited to memory, CPU, network bandwidth, and diskspace. The election token may also include a variety of other componentssuch as instance rank level, values indicating a device's desire (orlack thereof) to become active, etc. Note that the list presented is notfully exhaustive of the various ways in which an election token may bedetermined.

In an embodiment of the elector module 420 described in FIG. 4, thestate machine within the elector module 420, transitions betweendifferent states. The elector listens on the local IP multicast forelection tokens from other instances of the elector or similarlyimplemented or compatible embodiments on that IP multicast network. Uponreceipt of varying messages types and/or expiration of a timer withinthe elector module, the state machine determines, based on comparison ofnumerical values of the election token received from peers (denoted as“Peer Token” in FIG. 4) and its own token (denoted as “My Token” in FIG.4), whether the current instance of the embodiment shall transition toactive or inactive states. In one example embodiment, a particularelector module 420 “wins” the election if its token (in the form of arandom number) has the least/smallest value as compared to the randomnumber value of the tokens of its peers. Of course, this is only oneexample implementation for determining a winner—other embodiments mayuse other types of criteria for determining the winner of the election.

In the event an instance transitions to an active state, that instancebegins transmitting its own token onto the local IP multicast networksuch that other instances of the elector on such local IP multicast mayprocess the token according to similar or compatible embodiments of thestate machine logic.

Upon determination that the current entity is to be the active entity,the processor module 440 is notified of such determination—constitutingan activation of forwarding of IP multicast data traffic across aunicast network connection. At the same time, the elector transitions toa state of sending out its own beacon until such time that anotherelector on the network takes over control as described above.

Once forwarding is activated, the processor module 440 captures IPmulticast traffic received and transmitted by the application 210,forwarding such traffic across the unicast network connection 120 viathe network interface module 450. Such forwarding takes places in oneembodiment only if the far-end has registered a desire in receiving suchtraffic. Such determination is made by the far-end and communicated tothe processor module 440 on the local active entity via the unicastconnection 120.

Processor

The operation of the processor 440, as depicted in FIG. 6 rests in oneembodiment on the source of the data traffic entering the processormodule. If the traffic was received over a unicast connection, that datatraffic is passed on to the hosting/coupled application; giving theapplication the appearance that the data traffic was received on its ownlocal IP multicast interface. Such passing of data traffic from theembodiment to the hosting/coupled application may take a number of formsincluding, but not limited to, notification from the embodiment to theapplication through an application programming interface or insertioninto the data traffic flow between the application and the networkinterface.

If the traffic was received from the application either throughnotification of the application to the instance of the embodimentthrough an application programming interface, through insertion into theflow of network data traffic between the application and the networkinterface, or other viable means of interception or data trafficcapture; that data is encrypted, encapsulated, and distributed via theprocessor module 440 to all far-end entities coupled to the instance ofthe embodiment and who have registered a desire to receive such traffic.

In an embodiment, the processor module 440 makes use of well-knownencryption logic such as the Advanced Encryption Standard (AES) or othersuitable encryption technique to encrypt data to be transmitted acrossthe unicast network 120. The receiving end of the unicast connection120, upon receiving data traffic from a unicast transmitter, proceeds todecrypt that data traffic using the decryption logic employed by theencryption module on the transmitting end.

Additionally, in an embodiment, the processor module 440, may optionallymake use of data filtering and conversion functionality to facilitateenhanced transmission of forwarded data across the unicast connection120. Such data filtering may include, but is not limited, to mediare-packetization and transcoding; being the conversion of such mediabetween different data packet sizes and/or encoding types for purposesof bandwidth reduction, media enhancement, and other media-modificationfeatures desired by a user. Data filtering may also include specializeddata caching to further reduce the transport of redundant data acrossthe unicast link.

Site Identification

Returning to FIG. 5 wherein determination of a site identifier isdepicted, an instance of an embodiment determines, at initiation ofoperation, what the unique identifier is for the location or “site”where the instance is operating. Such an identifier is useful to theefficient operation of the embodiment as it is used to communicate tonodes at other sites the fact that a particular site—including theindividual application entities at that site—are no longer present onthe network. (The term “network” here being understood for oneembodiment to be the entire network and not just the individual sitenetwork or component of the entire network). Such tracking of thepresence of individual devices at remote locations allow devices atother locations to quickly and efficiently add or remove presenceinformation of said devices in the event of network outages and otherunforeseen events.

In an embodiment, determination of the site identifier is accomplishedby the flow chart depicted in FIG. 5. At initiation of activity, a localinstance of the identifier module 430 begins by listening on the localIP multicast network for a message from another similar or compatibleentity transmitting a site identifier. If such a message is received,the local instance stores this identifier and proceeds to use it in itsoperation as described below.

If no such identifier is received within a reasonable time, the localinstance determines whether it had previously received and stored anidentifier. If this is not the case, the local instance proceeds togenerate and store its own unique identifier according to a uniqueidentifier generation scheme such as the algorithm utilized to calculatea Globally Unique Identifier (GUID).

Subsequently, the local instance begins on-going transmission of thesite identifier—whether previously received and stored or previouslygenerated and stored. Once this process begins, an embodiment willcontinue to do so until such time the instance of the embodiment becomesinactive or is shut down.

Session Setup

In an embodiment, establishment and maintenance of a “session” betweentwo unicast entities is contemplated. Such a session is deemed to beestablished and maintained for the duration of the existence of a needfor the two entities on either end of a unicast network to be coupled.

In an embodiment, the establishment of a session is implemented via areliable unicast connection such as TCP between two entities—for examplenodes 200-F and 200-A from FIG. 1 and depicted as 400-A and 400-B inFIG. 7. Such establishment as shown in FIG. 7 item 900-A comprises, of amulti-stage interaction wherein the connecting entity 400-A initiates aconnection through a session setup request to entity 400-B. Suchrequest, upon being received by the entity 400-B causes entity 400-B togenerate a session encryption key to be used for encryption purposes inall subsequent interactions. The generation of the session encryptionkey may take the form of a number of methods including, but not limitedto, public/private key generation as part of an asymmetric cryptographytechnique such as Diffie-Helman, DSS, and RSA. This key is thencommunicated back to entity 400-A from entity 400-B using the unicastconnection established during the entity 400-A's session setup request.

The next step during stage 900-A constitutes entity 400-A encrypting(using the encryption keys generated and agreed upon during the stepdescribed above and an agreed-upon or previously configured algorithmsuch as AES) access, authentication, and authorization (AAA) informationincluding, but not limited to, a system identifier, a unique location or“site” identifier, client authorization and other identifyingcharacteristics required for the establishment of a session betweenentity 400-A and 400-B. Such encrypted information is transmitted toentity 400-B by entity 400-A over the unicast connection.

Upon receipt of aforementioned AAA information, entity 400-B proceeds togrant or deny access to entity 400-A—resulting in the final step instage 900-A of an acknowledgement of the session establishment. Suchprocessing of AAA information may include, but not be limited to,self-processing by entity 400-B or entity 400-B interfacing with anexternal entity such as RADIUS or ActiveDirectory for full or partialprocessing of the AAA information.

Session Streaming

Upon establishment of the session, an embodiment causes an iterativeinteraction 900-B, 900-C, and 900-D to ensue over the course of time,during which entity 400-A registers its intent to forward and receivedata traffic for unique address/port pairs the hosting/coupledapplication is processing. Such intent is based on activation of theprocessor module for unique address/port pairs as determined by theelector module 420 and described above. During a registration, entity400-A notifies its intent to forward and receive traffic for uniquestream identifiers, including but not limited to, address/port pairs bytransmitting details of said stream identifiers to the routing entity400-B. This action causes entity 400-B to establish forwarding androuting tables within itself in processor module 440 such that trafficreceived into entity 400-B is forwarded to other coupled entities overunicast whom have similarly registered such stream identifiers. Inresponse to the registration notification as described above, entity400-B transmits back to entity 400-A acceptance of the registrationnotification. This action causes entity 400-A to begin forwarding ofself-generated and local IP multicast traffic as, described above, toentity 400-B for distribution according to the logic flow chartdepicting such in FIG. 6. This action also causes entity 400-B toinclude distribution of locally received IP multicast data as well asdata received over unicast from other coupled entities (such as 400-C inFIG. 7) to entity 400-A.

Streaming of data over the unicast connection is then maintained for theduration of the registration. In an embodiment, such streaming may occurover a reliable unicast connection (such as TCP), over a “best-effort”connection utilizing a protocol such as UDP, or combination thereofaccording to desired preconfigured or dynamically determined performancerequirements. In such an embodiment, and where a best-effort unicastconnection is utilized for data streaming, entities participating in theunicast data stream connection may actively communicate from receivingentity to transmitting entity information such as packet loss statisticsand recommendations for packet loss concealment techniques to beemployed. Such packet loss concealment techniques include, but are notlimited to, oversending of packets by the transmitting entity, inclusionof components of previously transmitted packets within a packet,sequence numbers to track lost packet numbers for purposes of requestingresends of individual lost packets, and so forth. Note that numerousvarieties and embodiments of packet loss concealment techniques existand the afore-mentioned list does not constitute an exhaustive list ofsuch techniques that may be employed by an embodiment.

In an embodiment, data streamed over the unicast connection (reliable,best-effort, or otherwise) is encrypted utilizing the previouslydescribed encryption keys and associated algorithms. Such encrypted dataconstitutes the payload being transmitted over the unicast connectionand is preceded by encapsulation information such that the receivingentity may properly process the streamed data. Such encapsulationinformation includes, but is not limited to, the unique identifier ofthe transmitting entity and the source stream identifier from whence thepayload was obtained (and therefore the destination to which thetransmitting unicast endpoint wishes the data to be forwarded to). Suchstreaming interaction continues for the duration of the registration.

In the event a node such as 400-A becomes inactive for a particularstream identifier in accordance with the election logic detailedearlier, node 400-A proceeds to notify entity 400-B of its intent tostop further processing of data for that particular stream identifier.Such notification is similar in nature to the registration processdescribed earlier—the difference being that an unregistration isperformed rather than a registration operation. In response, entity400-B proceeds to remove from its routing table details of forwardingfor the unique stream identifier for the unregistering entity and ceasesto process data traffic received over the unicast connection from thatentity.

Part of the process of streaming data is the contemplation of detectionof duplicated data. Such an event may occur due to a variety of reasonsincluding, but not limited to transmission latency over the variousintervening networks, erroneous implementations within embodiments,invalid configurations by maintenance personnel or systems, and soforth. Such occurrences' may result in temporary or sustainedduplication of data traffic received from simultaneously active nodeswithin a particular IP multicast network.

Duplicate Detection

In an embodiment, duplicate detection falls within the purview of theprocessor module 440, which examines each packet and keeps track of alist of previously processed packets. For each packet a unique signatureis calculated according to the MD5 algorithm. This signature is storedin a list and the signature of each packet entering the processor module440 is compared against this list. In the event a duplicate signature isfound and certain thresholds are met, the packet is rejected—preventingfurtherforwarding of the duplicate packet and thereby creating a packetloop. The parameters defined for the length of the list and the relevantthresholds beyond which packets are not forwarded may be activelydetermined by the embodiment and/or defined by personnel or otherdevices acting in a maintenance role. It is noted that in oneembodiment, the algorithm used for packet signature determination mayinclude MD5 but is not limited to such algorithm. Any viable andapplicable algorithm may be utilized for this purpose in variousembodiments.

In summary of this description, interactions 900-B, 900-C, and 900-Dcontinue iteratively over the course of the session being established.

Session Teardown

In the event an entity of an embodiment becoming wholly inactive or inthe situation where no stream identifier are being processed by saidentity, the session previously established during step 900-A isdestroyed. This interaction takes the form of step 900-E wherein asession teardown message is transmitted by entity 400-A to entity 400-B.The action taken by entity 400-B in response to such message is toremove all entries for entity 400-A from its internal routing tables andto cease forwarding traffic to or processing traffic from entity 400-A.In an embodiment, such “ordered” teardown is not strictly required as asimple disconnection of the unicast connection between the entities issufficient enough to constitute an automatic tear down within eachentity.

The various operations represented in the illustrated flowcharts anddescribed above can be implemented in one embodiment by software orother computer-readable instructions encoded on or otherwise stored on acomputer-readable medium (such as a memory in the form of ROM, RAM,other type of hardware memory), and executable by one or moreprocessors. For example, the processor and computer-readable mediumstoring the computer-readable instructions can be present in one or moreof the devices described above, such as at the devices implementing thenodes 200-A, 200-F, etc. The processor 440, for example in oneembodiment, of the node 200 can execute the computer-readableinstructions stored in a memory or other computer-readable storagemedium at the node 200. In one embodiment, the variousmodules/components shown in FIGS. 2-3 can be implemented by software,hardware, and/or a combination of both. For instance, the application210 and certain components of the module 400 (shown in FIG. 3) can beimplemented as software stored on the computer-readable medium, andexecutable by the processor 440 (such as a processor implemented atleast in part by hardware).

The various embodiments described above can be combined to providefurther embodiments. All of the above U.S. patents, U.S. patentapplication publications, U.S. patent applications, foreign patents,foreign patent applications and non-patent publications referred to inthis specification and/or listed in the Application Data Sheet, areincorporated herein by reference, in their entirety. Aspects of theembodiments can be modified, if necessary to employ concepts of thevarious patents, applications and publications to provide yet furtherembodiments.

The above description of illustrated embodiments, including what isdescribed in the Abstract, is not intended to be exhaustive or to limitthe embodiments to the precise forms disclosed. While specificembodiments and examples are described herein for illustrative purposes,various equivalent modifications are possible and can be made.

For example, embodiments are not restricted to any particular data type,end device type, data format, communication format or protocol,manufacturer device model, network device type, specific sequence ofoperations (for example, some operations described herein may beperformed sequentially and/or simultaneously), etc.

These and other modifications can be made to the embodiments in light ofthe above detailed description. The terms used in the following claimsshould not be construed to be limited to the specific embodimentsdisclosed in the specification and the claims. Instead, the terms usedin the claims should be construed to include all possible embodimentsalong with the full scope of equivalents to which such claims areentitled. Accordingly, the claims are not limited by the disclosure.

1. A method for communicating in a communication network environment,said environment including at least a first, a second, and a third localarea network (LAN) separated from each other by a wide area network(WAN), said LANs being IP-multicast-capable and said WAN beingnon-IP-multicast-capable, the method comprising: electing a device insaid first LAN as a first distributed convergence node; designating adevice in said second LAN as a second distributed convergence node, saidsecond distributed convergence node being a routing distributedconvergence node; electing a device in said third LAN as a thirddistributed convergence node; and communicating traffic between saidfirst and third distributed convergence nodes via said routingdistributed convergence node, wherein said traffic can be communicatedbetween devices within each of said LANs using IP multicastcommunication, and wherein said traffic can be communicated between saidfirst distributed convergence node and said routing distributedconvergence node and between said routing distributed convergence nodeand said second distributed convergence node using unicastcommunication.
 2. The method of claim 1 wherein designating the devicein said second LAN as the second distributed convergence node includeselecting said device as the routing distributed convergence node.
 3. Themethod of claim 2 wherein electing a device in any of said LANs as adistributed convergence node includes electing a component of anapplication in said device as a distributed convergence node.
 4. Themethod of claim 1 wherein said communicating traffic between said firstand third distributed convergence nodes via said routing distributedconvergence node includes transparently communicating across said WANvia said routing distributed convergence node, such that each of saidfirst and third distributed convergence nodes communicate with eachother via said routing distributed convergence node as if said WAN isIP-multicast-capable.
 5. The method of claim 1, further comprising atleast one or more of: determining a site identifier associated with eachdistributed convergence node; performing dynamic oversending; applyingsecurity to traffic sent to and from said routing distributedconvergence node; or performing encapsulation of data contained in saidtraffic sent to and from said routing distributed convergence node. 6.The method of claim 1 wherein each distributed convergence node isadapted to receive first traffic from any other device in theirrespective LAN via IP multicast communication and is adapted to forwardsaid first traffic to said routing distributed convergence node viaunicast communication, and is further adapted to receive second trafficfrom said routing distributed convergence node via unicast communicationand to distribute said second traffic to devices in their respective LANvia IP multicast communication.
 7. The method of claim 1 wherein saidelecting includes using a state machine process to activate a state of adevice to indicate election thereof, a deactivated state of said deviceindicating non-election thereof.
 8. The method of claim 1 wherein saidcommunicating includes: performing a session setup stage between saidfirst distributed convergence node and said routing distributedconvergence node; performing a registration stage between said firstdistributed convergence node and said routing distributed convergencenode; conducting a data streaming stage between said first distributedconvergence node and said routing distributed convergence node andbetween said routing distributed convergence node and said thirddistributed convergence node; performing an unregistration stage betweensaid first distributed convergence node and said routing distributedconvergence node; and performing a session teardown stage between saidfirst distributed convergence node and said routing distributedconvergence node.
 9. A system for communicating in a communicationnetwork environment, said environment including at least a first, asecond, and a third local area network (LAN) separated from each otherby a wide area network (WAN), said LANs being IP-multicast-capable andsaid WAN being non-IP-multicast-capable, the system comprising: firstdistributed convergence node means in said first LAN for communicatingtraffic with devices in said first LAN using IP multicast communicationand for communicating traffic from said devices over said WAN viaunicast communication; second distributed convergence node means in saidsecond LAN for receiving said traffic communicated via unicastcommunication over said WAN from said first distributed convergence nodemeans, said second distributed convergence node means being a routingdistributed convergence node means for forwarding said traffic over saidWAN using unicast communication; third distributed convergence nodemeans in said third LAN for receiving said traffic communicated by saidrouting distributed convergence node over said WAN using unicastcommunication, said third distributed convergence node means furtherbeing for distributing said received traffic to devices in said thirdLAN via IP multicast communication and for communicating traffic fromsaid devices over said WAN to said routing distributed convergence nodevia unicast communication; and electing means for electing a device asfirst, second, and third distributed convergence nodes, said distributedconvergence nodes being dynamically changeable as a result of saidelecting.
 10. The system of claim 9, further comprising at least one ormore of: means for determining a site identifier associated with eachdistributed convergence node; means for performing dynamic oversending;means for applying security to traffic sent to and from said routingdistributed convergence node; means for detection duplicate packets intraffic; or means for performing encapsulation of data contained in saidtraffic sent to and from said routing distributed convergence node. 11.The system of claim 9, further comprising: means for performing asession setup stage between said first distributed convergence node andsaid routing distributed convergence node; means for performing aregistration stage between said first distributed convergence node andsaid routing distributed convergence node; means for conducting a datastreaming stage between said first distributed convergence node and saidrouting distributed convergence node and between said routingdistributed convergence node and said third distributed convergencenode; means for performing an unregistration stage between said firstdistributed convergence node and said routing distributed convergencenode; and means for performing a session teardown stage between saidfirst distributed convergence node and said routing distributedconvergence node.
 12. The system of claim 9 wherein said first, second,and third distributed convergence node means include a component of anapplication residing on a device.
 13. An apparatus adapted to be used ina communication network environment, said environment including at leasta first, a second, and a third local area network (LAN) separated fromeach other by a wide area network (WAN), said LANs beingIP-multicast-capable and said WAN being non-IP-multicast-capable, theapparatus comprising: a device having a distributed convergence nodemodule, said distributed convergence node module including: an electormodule to elect said device as a first distributed convergence node insaid first LAN; an identifier module to identify said device from otherdevices in said first LAN, including identification of said device asthe elected first distributed convergence node; and a network interfacein cooperation with a processor to communicate with said other devicesin said first LAN using IP multicast communication and to communicatewith a routing distributed convergence node in said second LAN via saidWAN using unicast communication if said device is elected as the firstdistributed convergence node, so as to allow said routing distributedconvergence node to forward communication via said WAN between saidfirst distributed convergence node in said first LAN and a thirddistributed convergence node in said third LAN.
 14. The apparatus ofclaim 13 wherein said distributed convergence node module is embodied insoftware executable by said processor.
 15. An apparatus adapted to beused in a communication network environment, said environment includingat least a first, a second, and a third local area network (LAN)separated from each other by a wide area network (WAN), said LANs beingIP-multicast-capable and said WAN being non-IP-multicast-capable, theapparatus comprising: a device having a routing distributed convergencenode module, said routing distributed convergence node module including:an elector module to elect said device as a routing distributedconvergence node in said second LAN; an identifier module to identifysaid device from other devices in said second LAN, includingidentification of said device as the elected routing distributedconvergence node; and a network interface in cooperation with aprocessor to communicate with said other devices in said second LANusing IP multicast communication and to communicate with a firstdistributed convergence node in said first LAN via said WAN usingunicast communication and to communicate with a third distributedconvergence node in said third LAN via said WAN using unicastcommunication, so as to forward traffic between said first and thirddistributed convergence nodes over said WAN.
 16. The apparatus of claim15 wherein said routing distributed convergence node module is embodiedin software executable by said processor.
 17. The apparatus of claim 15wherein said routing distributed convergence node module is adapted toperform a session setup stage between said first distributed convergencenode and said routing distributed convergence node, perform aregistration stage between said first distributed convergence node andsaid routing distributed convergence node, conduct a data streamingstage between said first distributed convergence node and said thirddistributed convergence node, perform an unregistration stage betweensaid first distributed convergence node and said routing distributedconvergence node, and perform a session teardown stage between saidfirst distributed convergence node and said routing distributedconvergence node.
 18. An article of manufacture adapted to be used in acommunication network environment, said environment including at least afirst, a second, and a third local area network (LAN) separated fromeach other by a wide area network (WAN), said LANs beingIP-multicast-capable and said WAN being non-IP-multicast-capable, thearticle of manufacture comprising: a computer-readable medium adapted tobe installed in one of said devices and having computer-readableinstructions stored thereon that are executable by a processor to: electsaid device as a distributed convergence node; identify said device fromother devices in a same LAN as said device, including identification ofsaid device as the elected distributed convergence node; and communicatewith said other devices in the same LAN using IP multicast communicationand communicate with another distributed convergence node via said WANusing unicast communication, so as to enable transparent communicationbetween distributed convergence nodes of different LANs via the WANusing unicast communication in a manner that makes said WAN appear to beIP-multicast-capable.
 19. The article of manufacture of claim 18 whereinsaid machine-readable medium is located in said device, which is electedas a routing distributed convergence node, such that said routingdistributed convergence node forwards traffic between distributedconvergence nodes of other LANs over the WAN using unicastcommunication.
 20. The article of manufacture of claim 18 wherein saidmachine-readable medium is located in said device, which is elected as adistributed convergence node to communicate with a routing distributedconvergence node, such that said elected distributed convergence nodecommunicates traffic with said routing distributed convergence node oversaid WAN using unicast communication so as to allow said routingdistributed convergence node to forward said traffic over said WAN toanother distributed convergence node of another LAN using unicastcommunication.